\title{Supplementary Information}
\author{
Group
}
\date{\today}

\documentclass[11pt,a4paper]{article}
\usepackage{graphicx}
%\usepackage{url}
\usepackage{hyperref}
%\usepackage{glossary}
%\makeglossary

%LaTeX loves to show how good it is at hyphenating words. That’s great but hypenated words are harder to read. Increase the hyphenation penalty:
\hyphenpenalty=5000
\tolerance=1000
%You may have to decrease the hyphen penalty if this results in words going beyond the margin

\begin{document}
\maketitle

%\begin{abstract}
%This paper explores issues surrounding the security of SCADA systems. It will provide an analysis and discussion of the sources of threats against SCADA systems and discuss possible mitigation strategies. 
%\end{abstract}

\section{Architecture}

\begin{figure}[ht]
   \begin{center}
       \includegraphics[scale=0.4]{../assets/clientarc}
       \caption{client}
       \label{client}
   \end{center}
\end{figure}

\begin{figure}[ht]
   \begin{center}
       \includegraphics[scale=1]{../assets/serverarc}
       \caption{server}
       \label{server}
   \end{center}
\end{figure}

\begin{figure}[ht]
   \begin{center}
       \includegraphics[scale=1]{../assets/connectionarc}
       \caption{connection}
       \label{connection}
   \end{center}
\end{figure}


\section{Future}

This project has culminated in a single, basic but functional prototype.  Obviously if the project were to be continued in the future it would almost certainly involve
large numbers of clients, probably in the thousands in any largish city.  As a result the developers would need to give special consideration to the stress that could place on the infrastructure (the server in particular) and effects felt as a result of this.


%------- perhaps the following two lines should be in the Future section rather than Testing?  - I'm(Fergus) moving it there and and addressing it for now.
%Can we give any idea of 3G network bandwidth required - don't want to give users bill shock. Need to say we have restricted updated to every 2 seconds but can vary it under load of 1000s of users. 
%Optimisation of information retrieval. Only send user `favourites' buses to them, as they likely do not want to see all buses, only their 3-4 routes. 



\subsection{Scalability}
\paragraph{Resource usage} would be a critical issue.  The prototype has not placed a huge emphasis on efficiency over ease and speed of development (due to the very limited number of man hours available) and currently receives data in text format from our dummy server, transmitting tens of bytes every two seconds, if not more.  If the current app were accidentally (or intentionally) left open for a significant amount of time, say 15-30 minutes, it could download what may be considered a large amount of data.  In a real deployment the data would certainly be in a much more compact format: it would be binary, some loss of precision would probably be acceptable, and compression techniques could be used.  It is unlikely that users would accept an app of this type (only intended to be used for short periods of time) if it made any appreciable difference to their data usage.  The app does not consume a large number of CPU cycles; very little work is done without user input, and even then the work is likely to be completed quickly.  The continued polling of the server may be enough to cause an undesirable increase in battery drain.  Current the app polls every two seconds, but testing may reveal a considerably longer interval acceptable to users, perhaps 5 or even 10 seconds, or maybe a short interval when the app is started and then moving to a longer interval later.  This would also help reduce data usage.

\paragraph{Other cities} are a likely future goal.  The original intention for this project was to make the app work with Adelaide Metro, but as contact with them was entirely one-way, a dummy server simulator was used instead.  Assumptions were made about the capabilities of the server: it would provide longitude, latitude, route number and and identification string for every bus at every request.  Either the app would have to be altered for each server it was used with, or code would have to be written to run on the server to meet the app interface requirements.  This would likely follow the very basic format used by the dummy server to avoid any incompatibility issues with any potential future servers used, with the only likely change being the ability to request only a subset of the data - data for only some buses, not all, to reduce bandwidth use.  This would be an improvement for both the user and the server operator.  Having to either modify the app or get permission to run code on the provider's server are both likely impediments to future uptake of the app.

\paragraph{Server owners} are going to shy away from any service that causes them trouble or costs them money.  Many thousands of uses accessing their servers with this app will increase their bandwidth costs, and may mean they need additional servers to handle the load, especially at peak hour times.  More servers mean increased costs, and even worse, the servers may even sit idle at times other than peak hour - a waste.  It is difficult to say a this time, from a developers point of view whether the the added convenience for users would be worth the increased costs.  Another point to consider is the difficulty in convincing the server owners to allow third party software to run on them.  Their may be security implications to consider, and who would be responsible for maintenance of the software?  This is not to say that these issues are certain to prevent adoption, but the may, and if not they may slow it.

\subsection{Features}
Time permitting, there are a number of features that would be added to the app, or at least tested:
\begin{itemize}
\item Directions: a function to find the quickest route by public transport from the user's location to any other location.  Would be similar to the Google Maps function that does the same, if not actually using the Google service.\footnote[1]{This was written almost to completion, but was not included because it was finally noticed that there was no way to use Google Directions data for Public Transit.  Only Walking and Driving were possible.}
\item Arrow indicators for buses: Arrow that indicate the direction of travel of buses.  Perhaps a toggle to enable/disable this to avoid clogging the screen.  Would be useful for long update intervals and zoomed out views.
\item Time to reach user: a function to display the estimated time a chosen bus will reach the closest point on it's route to the user (or another specified location).
\item Speed: function to display current average speed of chosen bus (or all buses).
\item Stopped indicator: display a different icon for buses that have stopped.
\item History Trail: option to begin drawing trails behind buses, to show history from time activated.
\item Stops: display stops on routes displayed.  Would be very useful for any user in an unfamiliar area.
\item Sift buses/routes by location: function to show only routes that come within a certain radius of a selected point (or perhaps buses that are currently within a certain radius).  The radius could be static or adjustable by dragging.
\end{itemize}
Last (in this document section) but not least (and not really a ``feature'') the app would be ported to other platforms: iOS, Blackberry, and possibly others such as Symbian and Meego.


\subsection{Features}
%Time permitting, there are a number of features that would be added to the app, or at least tested:
Extensions that could be added:
\begin{itemize}
\item Directions: a function to find the quickest route by public transport from the user's location to any other location.  Would be similar to the Google Maps function that does the same, if not actually using the Google service.\footnote[1]{This was written almost to completion, but was not included because it was finally noticed that there was no way to use Google Directions data for Public Transit.  Only Walking and Driving were possible.}
\item Arrow indicators for buses: Arrow that indicate the direction of travel of buses.  Perhaps a toggle to enable/disable this to avoid cluttering the screen.  Would be useful for long update intervals and zoomed out views.
\item Time to reach user: a function to display the estimated time a chosen bus will reach the closest point on it's route to the user (or another specified location).
\item Speed: function to display current average speed of chosen bus (or all buses).
\item Stopped indicator: display a different icon for buses that have stopped.
\item History Trail: option to begin drawing trails behind buses, to show history from time activated.
\item Sift buses/routes by location: function to show only routes that come within a certain radius of a selected point (or perhaps buses that are currently within a certain radius).  The radius could be static or adjustable by dragging.
\end{itemize}




\end{document}